home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-piscitello-ftp-bigports-02.txt < prev    next >
Text File  |  1993-07-30  |  9KB  |  331 lines
  1.  
  2. IETF                                1
  3. July 20, 1993    FTP Operation Over Big Address    Internet Draft
  4.  
  5.  
  6.          FTP Operation Over Big Address Records (FOOBAR)
  7.  
  8.  
  9.                        David M. Piscitello
  10.                             Bellcore
  11.                      dave@mail.bellcore.com
  12.  
  13.  
  14.                        Status of this Memo
  15.  
  16. This document is an Internet Draft.  Internet Drafts are working
  17. documents of the Internet Engineering Task Force (IETF), its
  18. Areas, and its Working Groups. Note that other groups may also
  19. distribute working documents as Internet Drafts.
  20.  
  21. Internet Drafts are draft documents valid for a maximum of six
  22. months. Internet Drafts may be updated, replaced, or obsoleted by
  23. other documents at any time.  It is not appropriate to use
  24. Internet Drafts as reference material or to cite them other than
  25. as a "working draft" or "work in progress."
  26.  
  27. Please check the Internet Draft abstract listing contained in the
  28. IETF Shadow Directories (cd internet-drafts) to learn the current
  29. status of this or any other Internet Draft.
  30.  
  31.  
  32.                           Introduction
  33.  
  34. This Internet-Draft specifies a method for assigning long
  35. addresses in the HOST-PORT specification for the data port to be
  36. used in establishing a data connection for File Transfer
  37. Protocol, FTP (RFC959, 1985). This is a general solution,
  38. applicable for all "next generation" IP alternatives, and can
  39. also be extended to allow FTP operation over transport interfaces
  40. other than TCP.
  41.  
  42.  
  43.                             Abstract
  44.  
  45. This paper describes a convention for specifying longer addresses
  46. in the PORT command.
  47.  
  48.  
  49.                          Acknowledgments
  50.  
  51. Many thanks to all the folks in the IETF who casually mentioned
  52. how to do this, but who left it to me to write the internet
  53. draft. Special thanks to Rich Colella, Bob Ullmann, Shawn
  54. Ostermann, Steve Lunt, and Brian Carpenter who had the time and
  55. decency to comment on the initial draft:-)
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68. IETF                                2
  69. Internet Draft               FOOBAR                 July 20, 1993
  70.  
  71.  
  72. 1.  Background
  73.  
  74. The PORT command of File Transfer Protocol allows users to
  75. specify an address other than the default data port for the
  76. transport connection over which data are transferred. The PORT
  77. command syntax is:
  78.  
  79. PORT <SP> <host-port> <CRLF>
  80.  
  81. The <host-port> argument is the concatenation of a 32-bit
  82. internet <host-address> and a 16-bit TCP <port-address>.  This
  83. address information is broken into 8-bit fields and the value of
  84. each field is transmitted as a decimal number (in character
  85. string representation).  The fields are separated by commas.  A
  86. port command is thus of the general form "PORT
  87. h1,h2,h3,h4,p1,p2", where h1 is the high order 8 bits of the
  88. internet host address.
  89.  
  90. To accommodate larger network addresses anticipated for all IP
  91. "next generation" alternatives, new commands and reply codes are
  92. needed for FTP. This memo addresses these needs.
  93.  
  94.  
  95. 2.  The LPRT Command
  96.  
  97. The LPRT command allows users to specify a "long" address for the
  98. transport connection over which data are transferred. The LPRT
  99. command syntax is:
  100.  
  101.             LPRT <SP> <long-host-port> <CRLF>
  102.  
  103. The <long-host-port> argument is the concatenation of the
  104. following fields;
  105.  
  106.    o  an 8-bit <address-family> argument (af)
  107.  
  108.    o  an 8-bit <host-address-length> argument (hal)
  109.  
  110.    o  a <host-address> of <host-address-length> (h1, h2, ...)
  111.  
  112.    o  an 8-bit <port-address-length> (pal)
  113.  
  114.    o  a <port-address> of <port-address-length> (p1, p2, ...)
  115.  
  116. The <address-family> argument takes the value of the protocol
  117. number of the "next generation" IP address (see Assigned Numbers,
  118. RFCxxxx, 1993), or generally speaking, a network layer protocol.
  119. Relevant assigned IPng version numbers are:
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134. IETF                                3
  135. July 20, 1993    FTP Operation Over Big Address    Internet Draft
  136.  
  137.  
  138.      Decimal         Keyword
  139.      ------          -------
  140.      0               reserved
  141.      1-3             unassigned
  142.      4               Internet Protocol (IP)
  143.      5               ST Datagram Mode
  144.      6               SIP
  145.      7               IX (from TP/IX)
  146.      8               PIP
  147.      9               TUBA/CLNP
  148.      10-14           unassigned
  149.      15              reserved
  150.  
  151. The value of each field is broken into 8-bit fields and the value
  152. of each field is transmitted as an unsigned decimal number (in
  153. character string representation, note that negative numbers are
  154. explicitly not permitted).  The fields are separated by commas.
  155.  
  156. A LPRT command is thus of the general form
  157.  
  158. LPRT af,hal,h1,h2,h3,h4...,pal,p1,p2...
  159.  
  160. where h1 is the high order 8 bits of the internet host address,
  161. and p1 is the high order 8 bits of the port number (transport
  162. address).
  163.  
  164.  
  165. 3.  The LPSV Command
  166.  
  167. The L(ONG) PASSIVE command requests the server-DTP to listen on a
  168. data port other than its default data port and to wait for a
  169. connection rather than initiate one upon receipt of a transfer
  170. command.  The response to this command includes the address
  171. family, host address length indicator, host address, port address
  172. length, and port address this server is listening on.  The reply
  173. code and text for entering the passive mode using a long address
  174. is 228 (Interpretation according to FTP is: positive completion
  175. reply 2yz, connections x2z, passive mode entered using long
  176. address xy8).  The suggested textual message to accompany this
  177. reply code is:
  178.  
  179. 228 Entering Long Passive Mode
  180. (af,hal,h1,h2,h3,h4...,pal,p1,p2...)
  181.  
  182.  
  183. 4.  Permanent Negative Completion Reply Codes
  184.  
  185. The negative completion reply codes that are associated with
  186. syntax errors in the PORT and PASV commands are appropriate for
  187. the LPRT and LPSV commands (500, 501). An additional negative
  188. completion reply code is needed to distinguish the case where a
  189. host supports the LPRT or LPSV command, but does not support the
  190. address family specified. Of the FTP function groupings currently
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200. IETF                                4
  201. Internet Draft               FOOBAR                 July 20, 1993
  202.  
  203.  
  204. defined for reply codes (syntax, information, connections,
  205. authentication and accounting, and file system), "connections"
  206. seems the most logical choice; thus, an additional negative
  207. command completion reply code, 521 is added, with the following
  208. suggested textual message:
  209.  
  210. 521 Supported address families are (af1, af2, ..., afn)
  211.  
  212. Where (af1, af2, ..., afn) are the values of the protocol numbers
  213. of the "next generation" or other protocol families supported.
  214. IP address noted earlier.
  215.  
  216.  
  217. 5.  Rationale
  218.  
  219. An explicit address family argument in the LPRT command and LPSV
  220. reply allows the Internet community to experiment with a variety
  221. of "next generation IP" alternatives within a common FTP
  222. implementation framework. (It also allows the use of a different
  223. address family on the command and data connections.) An explicit
  224. length indicator for the host address is necessary because some
  225. of the IPNG alternatives make use of variable length addresses.
  226. An explicit host address is necessary because FTP says it's
  227. necessary.
  228.  
  229. The decision to provide a length indicator for the port number is
  230. not as obvious, and certainly goes beyond the necessary condition
  231. of having to support TCP port numbers. Currently, at least one
  232. IPng alternative (TP/IX) supports longer port addresses. And
  233. given the increasingly "multi-protocol" nature of the Internet,
  234. it seems reasonable that someone, somewhere, might wish to
  235. operate FTP operate over Appletalk, IPX, and OSI networks as well
  236. as TCP/IP networks. (In theory, FTP should operate over *any*
  237. transport protocol that offers the same service as TCP.) Since
  238. some of these transport protocols may offer transport selectors
  239. or port numbers that exceed 16 bits, a length indicator may be
  240. desirable. If FTP must indeed be changed to accommodate larger
  241. network addresses, it may be prudent to determine at this time
  242. whether the same flexibility is useful or necessary with respect
  243. to transport addresses.
  244.  
  245.  
  246. 6.  Conclusions
  247.  
  248. The mechanism defined here is simple, extensible, and meets both
  249. IPNG and possibly multi-protocol internet needs.
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266. IETF                                5
  267. July 20, 1993    FTP Operation Over Big Address    Internet Draft
  268.  
  269.  
  270. 7.  References
  271.  
  272. RFC959          Postel, J., and Reynolds, J., "File Transfer Protocol"
  273.                 October 1985.
  274.  
  275. RFCxxxx         Reynolds, J., and Postel, J., "Assigned Numbers", <date>
  276.                 (probably does not include recently assigned IPv7 numbers).
  277.  
  278. RFC1123         Braden, R.,ed. "Requirements for Internet hosts -
  279.                 application and support", 1989 October.
  280.  
  281.  
  282. 8.  Author Information
  283.  
  284. David M. Piscitello
  285. Bell Communications Research
  286. NVC 1C322
  287. 331 Newman Springs Road
  288. Red Bank, NJ 07701
  289. dave@mail.bellcore.com
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.